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Abstract 

ProFIT is an extension of Standard Prolog 
with Features, Inheritance and Templates. 
ProFIT allows the programmer or gram- 
mar developer to declare an inheritance hi- 
erarchy, features and templates. Sorted 
feature terms can be used in ProFIT pro- 
grams together with Prolog terms to pro- 
vide a clearer description language for lin- 
guistic structures. ProFIT compiles all 
sorted feature terms into a Prolog term 
representation, so that the built-in Prolog 
term unification can be used for the uni- 
fication of sorted feature structures, and 
no special unification algorithm is needed. 
ProFIT programs are compiled into Pro- 
log programs, so that no meta-interpreter 
is needed for their execution. ProFIT thus 
provides a direct step from grammars de- 
veloped with sorted feature terms to Pro- 
log programs usable for practical NLP sys- 
tems. 

1 Introduction 

There are two key ingredients for building an NLP 
system: 

• a linguistic description 

• a processing model (parser, generator etc.) 

In the past decade, there have been diverging 
trends in the area of linguistic descriptions and in 
the area of processing models. Most large-scale lin- 
guistic descriptions make use of sorted feature for- 
malisms,^ but implementations of these formalisms 

1 Sorted feature structures are sometimes referred to 
as typed feature structures, e.g. in Carpenter's "Logic 
of Typed Feature Structures." We follow the usage in 
Logic Programming and the recent HPSG literature. 



are in general too slow for building practically usable 
NLP systems. Most of the progress in constructing 
efficient parsers and generators has been based on 
logic grammars that make use of ordinary Prolog 
terms. We provide a general tool that brings to- 
gether these developments by compiling sorted fea- 
ture terms into a Prolog term representation, so 
that techniques from logic programming and logic 
grammars can be used to provide efficient process- 
ing models for sorted feature grammars. 

In this introductory section, we discuss the advan- 
tages of sorted feature formalisms, and of the logic 
grammar paradigm, and show how the two devel- 
opments can be combined. The following sections 
describe the ProFIT language which provides sorted 
feature terms for Prolog, and its implementation. 

1.1 Grammar Development in Sorted 
Feature Formalisms 

Sorted feature formalisms are often used for the de- 
velopment of large-coverage grammars, because they 
are very well suited for a structured description of 
complex linguistic data. Sorted feature terms have 
several advantages over Prolog terms as a represen- 
tation langauge. 

1. They provide a compact notation. Features 
that are not instantiated can be omitted; there 
is no need for anonymous variables. 

2. Features names are mnemonic, argument posi- 
tions are not. 

3. Adding a new feature to a sort requires one 
change in a declaration, whereas adding an ar- 
gument to a Prolog functor requires changes 
(mostly insertion of anonymous variables) to ev- 
ery occurence of the functor. 

4. Specification of the subsort relationship is more 
convenient than constructing Prolog terms 
which mirror these subsumption relationships. 



Implementations of sorted feature formalisms such 



as TDL flKricger and Schafcr, 1994|), ALE ( |Car- 
penter, 1993|), CUF (porre and Dorna, 1993| ), TFS 
( Emele and Zajac, 1990| ) and others have been used 
successfully for the development and testing of large 
grammars and lexicons, but they may be too slow for 
actual use in applications because they are generally 
built on top of Prolog or LISP, and can therefore not 
be as efficient as the built-in unification of Prolog. 
There ar e a few logic programming langaug es, such 
as LIFE (|Ait-Kaci and Lincoln, 1989j ) or Oz flSmolka 
et al., 1995 ), that provide sorted feature terms, but 
no commercial implementations of these languages 
with efficient compilers are yet available. 



1.2 Efficient Processing based on Logic 
Grammars 

Much work on efficient processing algorithms has 
been done in the logic grammar framework. This 
includes work on 

• Compiling grammars into efficient parsers and 
generators: compilation of DCGs into (top- 
down) Prolog programs, left-corner parsers 
(BUP), LR parsers, head-corner parsers, and 
semantic-head driven generators. 

• Use of meta-programming for self-monitoring 
to ensure generation of unambiguous utterances 
(Neumann and van Noord, 199$ 



• Work in the area of Explanation-Based Learn- 
i ng (EBL) to learn frequently used structures 
( [gamuelsson, 1994 ) 



• Tabulation techniques, from the use of well- 
formed substring tables to the latest develop- 
ments in Earley deduction, and mcmoing tech- 
niques for logic programming (Neumann, 1994) 



• Work based on Constraint Logic Program- 
ming (CLP) to provide pr ocessing models for 
principle-based grammars ( Matiasek, 1994 ) 



• Using coroutining (dif, freeze etc.) to provide 
more efficient processing models 

• Partial deduction techniques to produce more 
efficient grammars 

• Using Prolog and its indexing facilities to build 
up a lexicon database 

Since much of this work involves compilation of 
grammars into Prolog programs, such programs can 
immediately benefit from any improvements in Pro- 
log compilers (for example the tabulation provided 



by XSB Prolog can provide a more efficient im- 
plementation of charts) which makes the grammars 
more usable for NLP systems. 

1.3 Combining Logic Grammars and 
Sorted Feature Formalisms 

It has been noted that first-order Prolog terms pro- 
vide the eq uivalent expres sive power as sorted fea- 
ture terms ( Mellish, 1992 ). For example, Car pen- 
ter's typed feature structures ( Carpenter, 1992 ) can 
easily be represented as Prolog terms, if the restric- 
tion is given up that the sort hierarchy be a bounded 
complete partial order. 

Such compilation of sorted feature terms into Pro- 
log terms has been successfully used in the Core 



Language Engine (CLE) (Alshawi, 1991) and in the 
Advanced Linguistic Engineering Platform (ALEP), 
QAlshawi et al., 1991| ).p| ProFIT extends the com- 



pilation techniques of these systems thro ugh the 



hand ling of multi-dimensional inheritance ( Erbach 



1994J) , and makes them generally available for a wide 



range of applications by translating programs (or 
grammars) with sorted feature terms into Prolog 
programs. 

ProFIT is not a grammar formalism, but rather 
extends any grammar formalism in the logic gram- 
mar tradition with the expressive power of sorted 
feature terms. 

2 The ProFIT Language 

The set of ProFIT programs is a superset of Pro- 
log programs. While a Prolog program consists only 
of definite clauses (Prolog is an untyped language), 
a ProFIT program consists of datatype declarations 
and definite clauses. The clauses of a ProFIT pro- 
gram can make use of the datatypes (sorts, features, 
templates and finite domains) that are introduced in 
the declarations. A ProFIT program consists of: 

• Declarations for sorts 

• Declarations for features 

• Declarations for templates 

• Declarations for finite domains 

• Definite clauses 



Similar, but less effic ient compila tion schemes are 
used in Hirsh's P-PATR (jkirsh 1986| ) and Covington's 
GULP system flCovington' 1989| ). 



2.1 Sort Declarations 

In addition to unsorted Prolog terms, ProFIT allows 
sorted feature terms, for which the sorts and features 
must be declared in advance. 

The most general sort is top, and all other sorts 
must be subsorts of top. Subsort declarations have 
the syntax given in ([!]). The declaration states that 
all Subi are subsorts of Super, and that all Subi are 
mutually exclusive. 



Super > [Subi 



, Sub„ 



(1) 



It is also possible to provide subsorts that are not 
mutually exclusive, as in (Q), where one subsort may 
be chosen from each of the "dimensions" connected 



by the * operator (Erbach, 1994) 



Super > [Subi.i, . . . , Subi, n ] * 



(2) 



[Sub 



k.l, 



, Sub 



k.m\ 



Every sort must only be defined once, i.e. it can 
appear only once on the left-hand side of the con- 
nective >. 

The sort hierarchy must not contain any cycles, 
i.e. there must be no sorts A and B, such that A ^ 
B, and A > B > A. 

The immediate subsorts of top can be declared 
to be extensional. Two terms which are of an ex- 
tensional sort are only identical if they have a most 
specific sort (which has no subsort), and if all fea- 
tures are instantiated to ground terms. If a sort is 
not declared as extensional, it is intcnsional. Two in- 
tensional terms are identical only if they have been 
unified. 

2.2 Feature Declarations 

Unlike unsorted feature formalisms (such as patr- 
ii), where any feature can be added to any struc- 
ture, ProFIT follows the notion of appropriateness 



in Carpenter's logic of typed feature structures (Car- 



penter, 1992 ), and introduces features for particular 
sorts. For each sort, one must declare which features 
are introduced by it. The features introduced by a 
sort are inherited by all its subsorts, which may also 
introduce additional features. A feature must be in- 
troduced only at one most general sort. This makes 
it possible to provide a notation in which the sort 
name can be omitted since it can be inferred from 
the use of a feature that is appropriate for that sort. 

This notion of appropriateness is desirable for 
structuring linguistic knowledge, as it prevents the 
ad-hoc introduction of features, and requires a care- 
ful design of the sort and feature hierarchy. Appro- 



priateness is also a prerequisite for compilation of 
feature terms into fixed-arity Prolog terms. 

Each feature has a sortal restriction for its value. 
If a feature's value is only restricted to be of sort 
top, then the sortal restriction can be omitted. The 
syntax of feature declarations is given in (0). 



Sort intro [Featurei : Restri, 



Feature n : Restr n ]. 



(3) 



The following declaration defines a sort bi- 
nary-tree with subsorts leaf and internal Lnode. The 
sort binary tree introduces the feature label and 
its subsort adds the features left_daughter and 
right_daughter . If a sort has subsorts and introduces 
features, these are combined in one declaration. 

binary _tree > [leaf , internal_node] 
intro [label] . 

internal_node 

intro [lef t_daughter : binary _tree , 

right_daughter : binary_tree] . 

2.3 Sorted Feature Terms 

On the basis of the declarations, sorted feature terms 
can be used in definite clauses in addition to and in 
combination with Prolog terms. A Prolog term can 
have a feature term as its argument, and a feature 
can have a Prolog term as its value. This avoids 
potential interface problems between different repre- 
sentations, since terms do not have to be translated 
between different languages. As an example, seman- 
tic representations in first-order terms can be used 
as feature values, but do not need to be encoded as 
feature terms. 

Sorted feature terms consist of a specification of 
the sort of the term (|4|), or the specification of a 
feature value (|5|), or a conjunction of terms (^|). A 
complete BNF of all ProFIT terms is given in the 
appendix. 



< Sort 
Feature ! Value 
Term & Term 



(4) 
(5) 
(6) 



The following clauses (based on hpsg) state that 
a structure is saturated if its subcat value is the 
empty list, and that a structure satisfies the Head 
Feature Principle (hf p) if its head features are iden- 



tical with the head features of its head daughter.]] 
Note that these clauses provide a concise notation 
because uninstantiated features can be omitted, and 
the sorts of structures do not have to be specified ex- 
plicitly because they can be infered from use of the 
features. 

saturated ( synsem ! local ! cat ! subcat ! <elist ). 

hfp( synsem ! local ! cat ! head ! X k 

dtrs ! head_dtr ! synsem ! local ! cat ! head! X ) . 

Note that conjunction also provides the possiblity 
to tag a Prolog term or feature term with a variable 
(Var & Term). 

2.4 Feature Search 

In the organisation of linguistic knowledge, feature 
structures are often deeply embedded, due to the 
need to group together sets of features whose value 
can be structure-shared. In the course of grammar 
development, it is often necessary to change the "lo- 
cation" of a feature in order to get the right struc- 
turing of information. 

Such a change of the "feature geometry" makes it 
necessary to change the path in all references to a 
feature. This is often done by introducing templates 
whose sole purpose is the abbreviation of a path to 
a feature. 

ProFIT provides a mechanism to search for paths 
to features automatically provided that the sortal 
restrictions for the feature values are strong enough 
to ensure that there is a unique minimal path. A 
path is minimal if it does not contain any repeated 
features or sorts. 

The sort from which to start the feature search 
must either be specified explicitly (^) or implic- 
itly given through the sortal restriction of a feature 
value, in which case the sort can be omitted and the 
expression (^) can be used. 

Sort >>> Feature ! Term (7) 
>>> Feature ! Term (8) 

The following clause makes use of feature search 
to express the Head Feature Principle (hfp). 

hfp( sign»>head!X & 

dtrs!head_dtr ! >»head!X ). 

While this abbreviation for feature paths is new 
for formal description languages, similar abbrevia- 
tory conventions are often used in linguistic publi- 
cations. They are easily and unambiguously under- 
stood if there is only one unique path to the feature 

3 These clauses assume appropriate declarations for 
the sort elist, and for the features synsem, local, 
cat, subcat, head, dtrs and head_dtr . 



which is not embedded in another structure of the 
same sort. 

2.5 Templates 

The purpose of templates is to give names to fre- 
quently used structures. In addition to being an 
abbreviatory device, the template mechanism serves 
three other purposes. 

• Abstraction and interfacing by providing a fixed 
name for a value that may change, 

• Partial evaluation, 

• Functional notation that can make specifica- 
tions easier to understand. 

Templates are defined by expressions of the form 
(Q) , where Name and Value can be arbitrary ProFIT 
terms, including variables, and template calls. There 
can be several template definitions with the same 
name on the left-hand side (relational templates). 
Since templates are expanded at compile time, tem- 
plate definitions must not be recursive. 

Name := Value. (9) 

Templates are called by using the template name 
prefixed with @ in a ProFIT term. 

Abstraction makes it possible to change data 
structures by changing their definition only at one 
point. Abstraction also ensures that databases (e.g. 
lexicons) which make use of these abstractions can 
be re-used in different kinds of applications where 
different datastructurcs represent these abstractions. 

Abstraction through templates is also useful for 
defining interfaces between grammars and process- 
ing modules. If semantic processing must access the 
semantic representations of different grammars, this 
can be done if the semantic module makes use of 
a template defined for each grammar that indicates 
where in the feature structure the semantic infor- 
mation is located, as in the following example for 

HPSG. 

semantics (synsem! local ! cont ! Sem) := Sem. 

Partial evaluation is achieved when a structure 
(say a principle of a grammar) is represented by a 
template that gets expanded at compile time, and 
does not have to be called as a goal during process- 
ing. 

We show the use of templates for providing func- 
tional notation by a simple example, in which the 
expression Of irst(X) stands for the first element of 
list X, and Orest (X) stands for the tail of list X, as 
defined by the following template definition. 



first ( [First I Rest] ) := First, 
rest ( [First I Rest] ) := Rest. 

The member relation can be denned with the fol- 
lowing clauses, which correspond very closely to the 
natural-language statement of the member relation 
given as comments. Note that expansion of the tem- 
plates yields the usual definition of the member re- 
lation in Prolog. 

'/, The first element of a list 
% is a member of the list . 
member (Of irst (List) ,List) . 

% Element is a member of a list 

7, if it is a member of the rest of the list 

member (Element .List) :- 

member (Element , @rest (List) ) . 

The expressive power of an n-place template is the 
same as that of an n+1 place fact. 

2.6 Disjunction 

Disjunction in the general case cannot be encoded in 
a Prolog term representation.^ Since a general treat- 
ment of disjunction would involve too much com- 
putational overhead, we provide disjunctive terms 
only as syntactic sugar. Clauses containing disjunc- 
tive terms are compiled to several clauses, one for 
each consistent combination of disjuncts. Disjunc- 
tive terms make it possible to state facts that belong 
together in one clause, as the following formulation 
of the Semantics Principle (sem_p) of HPSG, which 
states that the content value of a head-adjunct struc- 
ture is the content value of the adjunct daughter, 
and the content value of the other headed struc- 
tures (head-complement, head-marker, and head- 
filler structure) is the content value of the head 
daughter. 

sem_p( (<head_adj & 

»>cont!X & »>adj_dtr!»>cont!X ) 

or 

( ( <head_comp 
or <head_marker 
or <head filler 



) & 

»>cont!Y & »>head_dtr!»>cont!Y ) 



). 



For disjunctions of atoms, there exists a Prolog 
term representation, which is described below. 

2.7 Finite Domains 

For domains involving only a finite set of atoms as 
possible values, it is possible to provide a Prolog 
term representation (due to Colmerauer, and de- 
scribed by Mellish (Mellish, 1988)) to encode any 
subset of the possible values in one term. 



Consider the agreement features person (with val- 
ues 1 , 2 and 3) and number (with values sg and pi). 
For the two features together there are six possi- 
ble combinations of values (l&sg, 2&sg, 3&sg, l&pl, 
2&pl, 3&pl). Any subset of this set of possible values 
can be encoded as one Prolog term. The following 
example shows the declaration needed for this finite 
domain, and some clauses that refer to subsets of the 
possible agreement values by making use of the log- 
ical connectives ~ (negation), & (conjunction), or 
(disjunction) J^] 

agr fin_dom [1,2,3] * [sg.pl]. 

verb (sleeps, 3&sg) . 
verb(sleep, ~(3&sg)). 
verb(am, l&sg) . 
verb (is, 3&sg) . 
verb (are, 2 or pi). 



np('I', 
np(you, 



l&sg) . 
2@agr) . 



This kind of encoding is only applicable to do- 
mains which have no coreferences reaching into 
them, in the example only the agreement features 
as a whole can be coreferent with other agreement 
features, but not the values of person or number in 
isolation. This kind of encoding is useful to avoid 
the creation of choice points for the lexicon of lan- 
guages where one inflectional form may correspond 
to different feature values. 

2.8 Cyclic Terms 

Unlike Prolog, the concrete syntax of ProFIT allows 
to write down cyclic terms by making use of con- 
junction: 

X & f (X) . 

Cyclic terms constitute no longer a theoretical 
or practical problem in logic programming, and al- 
most all modern Prolog implementations can per- 
form their unification (although they can't print 
them out). Cyclic terms arise naturally in NLP 
through unification of non-cyclic terms, e.g., the 
Subcategorization Principle and the Spec Principle 
of HPSG. 

ProFIT supports cyclic terms by being able to 
print them out as solutions. In order to do this, 
the dreaded occur check must be performed. Since 
this must be done only when results are printed out 



see the complexity analysis by Brew (Brew, 1991) 



5 The syntax for finite domain terms is TermODomain. 
However, when atoms from a finite domains are com- 
bined by the conjunction, disjunction and negation con- 
nectives, the specification of the domain can be omitted. 
In the example, the domain must only be specified for 
the value 2, which could otherwise be confused with the 
integer 2. 



as ProFIT terms, it does not affect the runtime per- 
formance. 

3 From ProFIT terms to Prolog 
terms 

3.1 Compilation of Sorted Feature Terms 

The compilation of sorted feature terms into a Pro- 
log term representation is based on the following 
principles, which are explained in more detail in 
([Mellish, 198$ [Mellish, 199^ ; |Schoter, 1993| ; |Erbachj 
1994|). 



• The Prolog representation of a sort is an in- 
stance of the Prolog representation of its super- 
sorts. 

• Features are represented by arguments. If a fea- 
ture is introduced by a subsort, then the argu- 
ment is added to the term that further instan- 
tiates its supersort. 

• Mutually exclusive sorts have different functors 
at the same argument position, so that their 
unification fails. 

We illustrate these principles for compiling sorted 
feature terms into Prolog terms with an example 
from HPSG. The following declaration states that 
the sort sign has two mutually exclusive subsorts 
lexical and phrasal and introduces four features. 

sign > [lexical , phrasal] 
intro [phon , 

synsem, 
qstore , 
retrieved] . 

In the corresponding Prolog term representation 
below, the first argument is a variable whose only 
purpose is being able to test whether two terms are 
coreferent or whether they just happen to have the 
same sort and the same values for all features. In 



case of extensional sorts (see section 2.1), this vari- 



able is omitted. The second argument can be further 
instantiated for the subsorts, and the remaining four 
arguments correspond to the four features. 
$sign (Var , LexPhras , Phon , Synsem , Qstore , Retr iev) 

The following declaration introduces two sort hier- 
archy "dimensions" for subsorts of phrasal, and one 
new feature. The corresponding Prolog term repre- 
sentation instantiates the representation for the sort 
sign further, and leaves argument positions that can 
be instantiated further by the subsorts of phrasal, 
and for the newly introduced feature daughters. 

phrasal > [headed, non_headed] * [decl , int ,rel] 
intro [daughters] . 



$sign(Var , 

Sphrasal (Phrasesort , Clausesort , Dtrs) , 

Phon, 

Synsem, 

Qstore , 

Retrieved) 

3.2 Compilation of Finite Domains 

The compilation of finite domains into Prolog terms 
is p erformed by t he "brute-force" method described 
in ( Mellish, 1988 ). A finite domain with n possible 
domain elements is represented by a Prolog term 
with n + 1 arguments. Each domain element is as- 
sociated with a pair of adjacent arguments. For ex- 
ample, the agreement domain agr from section 2.7 
with its six elements (l&sg, 2&sg, 3&sg, l&pl, 2&pl, 
3&pl) is represented by a Prolog term with seven ar- 
guments. 

$agr(l,A,B,C,D,E,0) 

Note that the first and last argument must be 
different. In the example, this is achieved by in- 
stantiation with different atoms, but an inequality 
constraint (Prolog n's dif) would serve the same 
purpose. We assume that the domain element l&sg 
corresponds to the first and second arguments, 2&sg 
to the second and third arguemnts, and so on, as il- 
lustrated below. 

$agr( 1,A,B,C,D,E,0) 
lsg 2sg 3sg lpl 2pl 3pl 

A domain description is translated into a Pro- 
log term by unifying the argument pairs that are 
excluded by the description. For example, the do- 
main description 2 or pi excludes l&sg and 3&sg, 
so that the the first and second argument are unified 
(l&sg), as well as the third and fourth (3&sg). 

$agr(l ) l ) X ) X ) D ) E > 0) 

When two such Prolog terms are unified, the union 
of their excluded elements is computed by unificata- 
tion, or conversely the intersection of the elements 
which are in the domain description. The unifica- 
tion of two finite domain terms is successful as long 
as they have at least one element in common. When 
two terms are unified which have no element in com- 
mon, i.e., they exclude all domain elements, then 
unification fails because all arguments become uni- 
fied with each other, including the first and last ar- 
guments, which are different. 

4 Implementation 

ProFIT has been implemented in Quintus and Sics- 
tus Prolog, and should run with any Prolog that con- 
forms to or extends the proposed ISO Prolog stan- 
dard. 



All facilities needed for the development of appli- 
cation programs, for example the module system and 
declarations (dynamic, multifile etc.) are supported 
by ProFIT. 

Compilation of a ProFIT file generates two kinds 
of files as output. 

1. Declaration files that contain information for 
compilation, derived from the declarations. 

2. A program file (a Prolog program) that con- 
tains the clauses, with all ProFIT terms com- 
piled into their Prolog term representation. 

The program file is compiled on the basis of the 
declaration files. If the input and output of the pro- 
gram (the exported predicates of a module) only 
make use of Prolog terms, and feature terms are only 
used for internal purposes, then the program file is 
all that is needed. This is for example the case with 
a grammar that uses feature terms for grammati- 
cal description, but whose input and output (e.g. 
graphemic form and logical form) are represented as 
normal Prolog terms. 

Declarations and clauses can come in any order in 
a ProFIT file, so that the declarations can be writ- 
ten next to the clauses that make use of them. Dec- 
larations, templates and clauses can be distributed 
across several files, so that it becomes possible to 
modify clauses without having to recompile the dec- 
larations, or to make changes to parts of the sort 
hierarchy without having to recompile the entire hi- 
erarchy. 

Sort checking can be turned off for debugging 
purposes, and feature search and handling of cyclic 
terms can be turned off in order to speed up the 
compilation process if they are not needed. 

Error handling is currently being improved to give 
informative and helpful warnings in case of unde- 
fined sorts, features and templates, or cyclic sort hi- 
erarchies or template definitions. 

For the development of ProFIT programs and 
grammars, it is necessary to give input and output 
and debugging information in ProFIT terms, since 
the Prolog term representation is not very readable. 
ProFIT provides a user interface which 

• accepts queries containing ProFIT terms, and 
translates them into Prolog queries, 

• converts the solutions to the Prolog query back 
into ProFIT terms before printing them out, 

• prints out debugging information as ProFIT 
terms. 



When a solution or debugging information is 
printed out, uninstantiated features are omitted, 
and shared structures are printed only once and rep- 
resented by variables on subsequent occurences. 

A pretty-printer is provided that produces a 
neatly formatted screen output of ProFIT terms, 
and is configurable by the user. ProFIT terms can 
also be output in I^TgX format, and an interface to 
the graphical feature editor Fegramed is foreseen. 

In order to give a rough idea of the efficiency gains 
of a compilation into Prolog terms instead of using a 
feature term unification algorithm implemented on 
top of Prolog, we have compared the runtimes with 
ALE and the Eisele-Dorre algorithm for unsorted 
feature unification for the following tasks: (i) uni- 
fication of (unsorted) feature structures, (ii) unifi- 
cation of inconsistent feature structures (unification 
failure), (iii) unification of sorts, (iv) lookup of one 
of 10000 feature structures (e.g. lexical items), (v) 
parsing with an HPSG grammar to provide a mix of 
the above tasks. 

The timings obtained so far indicate that ProFIT 
is 5 to 10 times faster than a system which imple- 
ments a unification algorithm on top of Prolog, a 
r esult which is predicted by the studies of Schotcr 
(3ch6ter, 1993) and the experience of the Core Lan- 
guage Engine. 

The ProFIT system and documentation are avail- 
able free of charge by anonymous ftp (server: 
ftp.coli.uni-sb.de, directory: pub/profit). 

5 Conclusion 

ProFIT allows the use of sorted feature terms in Pro- 
log programs and Logic Grammars without sacrific- 
ing the efficiency of Prolog's term unification. It is 
very likely that the most efficient commercial Prolog 
systems, which provide a basis for the implementa- 
tion of NLP systems, will conform to the proposed 
ISO standard. Since the ISO standard includes nei- 
ther inheritance hierarchies nor feature terms (which 
are indispensible for the development of large gram- 
mars, lexicons and knowledge bases for NLP sys- 
tems), a tool like ProFIT that compiles sorted fea- 
ture terms into Prolog terms is useful for the devel- 
opment of grammars and lexicons that can be used 
for applications. ProFIT is not a grammar formal- 
ism, but rather aims to extend current and future 
formalisms and processing models in the logic gram- 
mar tradition with the expressive power of sorted 
feature terms. Since the output of ProFIT compila- 
tion are Prolog programs, all the techniques devel- 
oped for the optimisation of logic programs (partial 
evaluation, tabulation, indexing, program transfor- 
mation techniques etc.) can be applied straightfor- 



wardly to improve the performance of sorted feature 
grammars. 
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